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Definition 


Definition:  A  SLA  is  an  agreement  between  a 
provider  of  services  and  a  customer  that  defines  a 
level  of  performance  or  a  quality  of  service. 

SLAs  define  in  measurable  terms  the  service  to  be 
performed,  the  level  of  service  that  is  acceptable, 
and  the  means  to  determine  if  the  service  is  being 
provided  at  the  agreed  upon  levels. 


SLA  Development 


•  Define  the  problem 

•  Develop  a  team 

•  Review  current  services 

•  Determine  requirements 

•  Start  SLA  development 

•  Determine  SLM 


SLA  Development 


•  Negotiate  the  services 

•  Determine  performance  thresholds 

•  Agree  on  escalation  procedures 

•  Establish  penalties  and/or  incentives 

•  Document  the  SLA 

•  Review  and  refine  over  time. 


Requirements  Analysis 


The  SLA  development  process  better  defines 
requirements  by  focusing  on  quantitative  metrics 

SLAs  facilitate  communication 

Development  includes  multiple  perspectives 
including  process  owners,  users,  developers,  and 
service  providers 

Developing  the  SLAs  identifies  constraints  on  the 
project  in  terms  of  personnel,  resources,  funds, 
technical  capability,  and  time. 


Design 


Quality  metrics  ensures  developers  are  focusing 
on  quality  early  in  the  development  process 

Realistic  quantifiable  requirements  can  be  used  to 
determine  architecture  and  design.  Allows  analysis, 
risk  assessment  and  trade  offs. 

Availability  constraints  may  drive  code  reuse, 
complexity  analysis,  and  better  testing/simulation. 
Allows  analysis,  risk  assessment  and  trade  offs. 

SLA  may  drive  user-centric  view  of  availability 


Program  Management 


Focuses  management  attention  on  SLAs 

Cost-Benefit  analysis 

SLAs  drive  monitoring,  trend  analysis  and 
capacity  management 

Maintainability  thresholds  promote  accurate 
configuration  management,  better  documentation, 
more  efficient  problem  resolution  procedures, 
better  backup  and  disaster  recovery  plans,  and 
better  integrity 


SLA  Benefits 


Quality  is  something  that  must  be  planned 

Software  quality  cannot  be  measured  without 
proper  monitoring 

Ensures  both  parties  understand  the  services  to 
provided  and  the  quality  expected 

SLAs  set  user  expectations  through  defined 
performance  levels 

SLAs  help  drive  the  managerial  oversight  to 
ensure  that  quality  processes  are  adopted  and 
adhered  to 


SLA  Challenges 


Must  have  a  well  defined  and  knowledgeable 
SLM  organization  with  the  authority  to  manage 
the  SLAs.  NMCI  does  not  have  this. 

PMs  are  Functional  experts  with  little  IT  skills. 
PMs  are  too  willing  to  accept  contractor  provided 
SLAs.  The  PMs  are  often  forced  to  rely  on 
contractors  for  technical  support 

Complex  heterogeneous,  distributed  systems 
makes  end-to-end  SLAs  are  very  difficult  to  write 
and  enforce 


SLA  Challenges 


Contracting  personnel  and  management  must  be 
willing  to  enforce  the  SLA  penalties 

Difficult  to  define  services  and  service  levels  to  a 
litigious  level 

Costly  in  terms  of  manpower  to  develop,  perform 
benchmark  analysis  and  verify  compliance 

Determining  meaningful  and  measurable 
performance  metrics 

Establishing  realistic  expectations 


Conclusion 


SLAs  are  difficult  to  construct,  but  they  are 
crucial  to  quality  management.  Without 
SLAs  quality  assurance  cannot  happen. 


